1. Technical Field
This invention generally relates to computer systems and more specifically relates to graphical user interfaces for computer systems.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices that may be found in many different settings. Computer systems typically include a combination of hardware (e.g., semiconductors, circuit boards, etc.) and software (e.g., computer programs). As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
Early computer systems used command-based operating systems and software applications. These command-based systems provided a user interface that required the user to memorize a relatively large number of commands in order to perform meaningful work. The user interfaces for these command-driven computer programs required a relatively high level of skill to operate, and were not considered to be xe2x80x9cuser-friendly.xe2x80x9d With the introduction of the IBM personal computer (PC), computers became more widely available, both in the workplace and in homes, and the computer industry soon recognized the need to provide more user-friendly interfaces to computer programs. As a result, many different operating systems were introduced that provided a graphical user interface (GUI), including IBM""s OS/2, Microsoft Windows, and the Apple McIntosh. Software applications with graphical user interfaces soon followed, and the vast majority of computer programs running on personal computers today provide a user-friendly graphical user interface.
One trend in graphical user interfaces is to separate the functions of the portion that does the underlying work and manipulates data, known as the model, from the graphical presentation to the user, known as the view. This trend has led to the development of a paradigm known as a model view controller, which attempts to keep the model separate from the view and controller functions so that changes to the model do not affect the view, and vice versa. The model view controller also makes it possible for may different views to be associated with a single model.
There are circumstances when the view may desire to know the state of the model. For example, if the model is busy performing some work, such as communicating over a network or performing file input/output (I/O), it would be nice to display an indication on the view presented to the user that the model was busy. One way to accomplish the indication of a busy model is to have the model itself present some indication to the user. However, this is clearly a violation of the model view controller paradigm because the model would now be responsible for some user interface code, and would have to provide the same indication to all views associated with the model. In the alternative, the view could poll the model at regular intervals to see if the model is working, and provide an indication to the user when the model is busy. However, if the polling interval is too short, overall performance of the application can be adversely affected. If the polling interval is too long, the indication can be ineffective or inaccurate. Without an efficient mechanism that provides an indication to the user of the state of the model without violating the model view controller paradigm, the computer industry will continue to suffer from applications that either provide no indication of the state of the model to the user when the model is busy, that violate the model view controller paradigm, or that provide the indication at a significant performance cost.
According to the preferred embodiments, a model view controller has a model and a view with one or more listeners, and each listener may register with the model when the listener desires to be notified of a change of state in the model. When the model is about to change its state, it notifies all registered listeners, and after the model has changed its state, it notifies all registered listeners again. The present invention thus allows the model to notify the view when the state of the model changes, and the view can then decide what actions to perform. One suitable example allows the model to notify all registered listeners before performing network communications, which would allow the view to disable the component on the graphical user interface and present a suitable wait cursor, such as an hourglass or a clock face. Once the network communications are complete, the model notifies all registered listeners that the model is no longer busy, which causes the view to change the cursor back to the default cursor and to enable the graphical user interface component again. The present invention thus achieves efficient user notification of the state of the model within the constraints of the model view controller paradigm.
The foregoing and other features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings.